home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3365 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.8 KB
  1. Path: EU.net!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Non-standard exception handling
  4. Message-ID: <1996Jan23.173823.1753@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 23 Jan 96 17:38:23 WET
  7. References: <3102B39F.3CC9@cts.com>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <3102B39F.3CC9@cts.com> "Steven K. Sharp" <sksharp@cts.com>  
  12. writes:
  13.  
  14. [snip]
  15.  
  16. > I feel that they should be using exceptions to handle these things.  
  17. > It's more understood and generally cleaner. 
  18.  
  19. How to do proper error handling using the C++ exception mechanism is still  
  20. a controversial issue. Some experts prefer old tried and tested techniques  
  21. using function return values, error numbers and the like, others feel  
  22. exception handling is superior. There are a few examples around that show  
  23. proper exception generation and -handling when doing complicated stuff can  
  24. be notoriously difficult.  
  25.  
  26. > It also forces handling 
  27. > of the exception rather than being able to skip any error handling.
  28.  
  29. C++ gives us the option of catching exceptions, it doesn't force us to do  
  30. so. If we forget to catch an exception, the program will abort, which is  
  31. sometimes, but not always, the most reasonable thing to do.
  32.  
  33. > Which leads to other questions.  When should you throw an exception? 
  34. > Should they only be thrown when the program is in such a state that 
  35. > you have no idea what's going on?  
  36.  
  37. When throwing an exception that is supposed to be caught somewhere, we are  
  38. relying on the exception-awareness of various parts of the program. Some  
  39. of these parts may be coming from libraries written before exceptions were  
  40. introduced in the language, or by exception-unware programmers. If this is  
  41. the case, your program will be in an unstable state at the point where you  
  42. catch the exception.
  43. In general, exception-aware code must be written using RAI (Resource  
  44. Aquisition is Initialization) idioms, which is at odds with more symbolic  
  45. (Smalltalk-like-) programming styles, in which resource management is  
  46. considered to be a non-issue.
  47.  
  48. All in all, the situation is quite messy, and considering how long it took  
  49. various  compiler vendors to properly implement exception handling and the  
  50. amount of legacy code around, it is likely to stay messy for a long time.  
  51. My advice would be: 
  52.  
  53. - Be prepared to properly handle exceptions thrown by others: make sure  
  54. your objects are in a `destructor-ready' state when calling a function  
  55. that might throw one. In principle, all automatic (local) raw pointers to  
  56. heap allocated objects should be replaced by smart pointer objects.   
  57. - Don't rely on the exception-awareness of code you're not familiar with.
  58. - Don't force users of your code to be exception-aware: only throw an  
  59. exception when you see no other way out. If you do so, clearly state this  
  60. in the documentation of your code.
  61.  
  62. - Wil
  63.